docs: add POST /api/notifications endpoint#48
Conversation
Add notification email endpoint documentation following the send_email MCP tool definition. Supports to, cc, subject, text (Markdown), html, custom headers, and room_id for chat footer links. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
|
Warning Rate limit exceeded
⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. 📒 Files selected for processing (3)
📝 WalkthroughWalkthroughThis PR introduces documentation and specification for a new notification API endpoint (POST /api/notifications) that sends notification emails via the Resend API. It adds OpenAPI schema definitions for the request and response payloads, a reference documentation page, and updates navigation configuration. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
api-reference/openapi.json (1)
3916-3935: Define required fields inNotificationResponsefor stable generated types.Without a
requiredarray, all response properties are optional in generated SDKs.Suggested schema tightening
"NotificationResponse": { "type": "object", + "required": ["success", "message", "id"], "properties": {🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@api-reference/openapi.json` around lines 3916 - 3935, The NotificationResponse schema currently leaves all properties optional which weakens generated types; update the "NotificationResponse" OpenAPI schema to include a "required" array listing the fields that must always be present (e.g., "success", "message", and "id") so SDKs and validators will treat those properties as non-optional; modify the JSON definition for the NotificationResponse object to add the required entry while keeping existing property descriptions and examples intact.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@api-reference/openapi.json`:
- Around line 3866-3915: The CreateNotificationRequest schema currently allows
an empty recipient list and payloads without a body; update the
CreateNotificationRequest object to require a non-empty "to" array (add
"minItems": 1 to the "to" property) and enforce that at least one message body
is provided by adding an anyOf (or oneOf) at the object level that requires
either "text" or "html" (e.g., anyOf:
[{"required":["text"]},{"required":["html"]}]). Keep "to" and "subject" as
required but add these schema keywords to ensure valid recipients and
message-body invariants.
---
Nitpick comments:
In `@api-reference/openapi.json`:
- Around line 3916-3935: The NotificationResponse schema currently leaves all
properties optional which weakens generated types; update the
"NotificationResponse" OpenAPI schema to include a "required" array listing the
fields that must always be present (e.g., "success", "message", and "id") so
SDKs and validators will treat those properties as non-optional; modify the JSON
definition for the NotificationResponse object to add the required entry while
keeping existing property descriptions and examples intact.
| "CreateNotificationRequest": { | ||
| "type": "object", | ||
| "required": ["to", "subject"], | ||
| "properties": { | ||
| "to": { | ||
| "type": "array", | ||
| "items": { | ||
| "type": "string", | ||
| "format": "email" | ||
| }, | ||
| "description": "Recipient email addresses", | ||
| "example": ["user@example.com"] | ||
| }, | ||
| "cc": { | ||
| "type": "array", | ||
| "items": { | ||
| "type": "string", | ||
| "format": "email" | ||
| }, | ||
| "description": "Optional CC email addresses", | ||
| "example": ["cc@example.com"] | ||
| }, | ||
| "subject": { | ||
| "type": "string", | ||
| "description": "Email subject line", | ||
| "example": "Weekly Pulse Report" | ||
| }, | ||
| "text": { | ||
| "type": "string", | ||
| "description": "Plain text or Markdown body. Rendered as HTML via Markdown if no `html` is provided.", | ||
| "example": "# Pulse Report\n\nHere's your weekly summary." | ||
| }, | ||
| "html": { | ||
| "type": "string", | ||
| "description": "Raw HTML body. Takes precedence over `text` when both are provided.", | ||
| "example": "<h1>Pulse Report</h1><p>Here's your weekly summary.</p>" | ||
| }, | ||
| "headers": { | ||
| "type": "object", | ||
| "additionalProperties": { | ||
| "type": "string" | ||
| }, | ||
| "description": "Optional custom email headers" | ||
| }, | ||
| "room_id": { | ||
| "type": "string", | ||
| "description": "Room ID to include a chat link in the email footer" | ||
| } | ||
| } | ||
| }, |
There was a problem hiding this comment.
Enforce message-body and recipient invariants in CreateNotificationRequest.
The schema currently permits payloads with to + subject but no text/html, and also allows an empty to array. That under-specifies valid requests.
Suggested schema fix
"CreateNotificationRequest": {
"type": "object",
"required": ["to", "subject"],
+ "anyOf": [
+ { "required": ["text"] },
+ { "required": ["html"] }
+ ],
"properties": {
"to": {
"type": "array",
+ "minItems": 1,
"items": {
"type": "string",
"format": "email"
},🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@api-reference/openapi.json` around lines 3866 - 3915, The
CreateNotificationRequest schema currently allows an empty recipient list and
payloads without a body; update the CreateNotificationRequest object to require
a non-empty "to" array (add "minItems": 1 to the "to" property) and enforce that
at least one message body is provided by adding an anyOf (or oneOf) at the
object level that requires either "text" or "html" (e.g., anyOf:
[{"required":["text"]},{"required":["html"]}]). Keep "to" and "subject" as
required but add these schema keywords to ensure valid recipients and
message-body invariants.
The recipient email is now automatically resolved from the authenticated account's API key or Bearer token. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
First SDK/CLI documentation page. Documents the notifications command usage, options, examples, and its API equivalent. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Document the @recoupable/cli package with installation, auth setup, and headings for all commands: whoami, artists, chats, sandboxes, orgs, and notifications. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Summary
POST /api/notificationsendpoint documentation following thesend_emailMCP tool definitionto,cc,subject,text(Markdown),html, customheaders, androom_idfor chat footer linksCreateNotificationRequestandNotificationResponseschemas to OpenAPI specTest plan
npx mintlify@latest dev🤖 Generated with Claude Code
Mintlify
0 threads from 0 users in Mintlify
Summary by CodeRabbit
Release Notes
New Features
Documentation